add terraform to provision packet machine#22
Conversation
|
/hold |
|
/hold cancel |
|
overall looks great to me. Not a blocker at all but we'll probably want parameterise the ip range for the iptable rule |
hack/prebuild/main.tf
Outdated
| } | ||
|
|
||
| resource "packet_ssh_key" "key" { | ||
| name = "unlikely_tf_ssh_key_name" |
There was a problem hiding this comment.
You should put ${var.environment_id} here.
hack/prebuild/main.tf
Outdated
| @@ -0,0 +1,32 @@ | |||
| resource "packet_project" "libvirt_actuator" { | |||
| name = "libvirt-actuator tests" | |||
There was a problem hiding this comment.
Maybe put ${var.environment_id} here.
hack/prebuild/main.tf
Outdated
| } | ||
|
|
||
| resource "packet_device" "libvirt" { | ||
| hostname = "${var.environment_id}" |
There was a problem hiding this comment.
Prepend something non alpha numeric, in case uuid generates a number fist.
hack/prebuild/init.sh
Outdated
|
|
||
| echo 'LIBVIRTD_ARGS="--listen"' >> /etc/sysconfig/libvirtd | ||
|
|
||
| iptables -I INPUT -p tcp --dport 16509 -j ACCEPT -m comment --comment "Allow insecure libvirt clients" |
There was a problem hiding this comment.
Are the tests going to use TCP or SSH as a transport for libvirt? I don't think it's okay to run these with unauthenticated libvirt listening on the public internet.
There was a problem hiding this comment.
For CI I was thinking on parameterising the ip range allowed to access and then reuse your tls stuff, so we test it as it's consumed by the installer/mao. wdyt?
There was a problem hiding this comment.
Yeah, that sounds good. I'm not familiar with the e2e tests or the plan for those. Do they use the installer? If so, I think this should be on-hold until openshift/installer#296 merges.
There was a problem hiding this comment.
Eventually we might use installer. Currently for mao/aws-actuator we use terraform to create the minimal infra needed to satisfy some actuator assumptions and verify expected behaviour,
See https://github.com/openshift/machine-api-operator/tree/master/tests
e.g The minimal infra for libvirt actuator will contain a network and the ign volumes
There was a problem hiding this comment.
Ah, cool. Then I think it should be pretty easy to use TLS or SSH as the transport from the start. There aren't really any changes required for the actuator. The credentials, certs or SSH keys, just need to be available and the right URI needs to be used. The libvirt library will handle the rest.
There was a problem hiding this comment.
Just to add a little more detail on making TLS work: here's a link to the docs
We just need to generate the TLS assets somehow -- could use certtool, cfssl, or even Terraform if we don't want to use the Go tool in the installer PR. Then configure libvirtd to point to the certs and use a URI like: qemu+tls://$IP/system?pkipath=/path/to/certs
That should be enough and pretty secure as long as no one can access the generated certs and they are one-time use.
There was a problem hiding this comment.
It would be probably easier to adapt it to use SSH as this already need SSH keys to connect to instance. WDYT?
There was a problem hiding this comment.
Totally fine. As long as we're doing authentication and encryption somehow.
hack/prebuild/main.tf
Outdated
| @@ -0,0 +1,32 @@ | |||
| resource "packet_project" "libvirt_actuator" { | |||
There was a problem hiding this comment.
Does this create a project for every build? We probably want a single re-used project. That will let us manage permissions for it.
|
/hold |
|
/hold cancel |
| set +e | ||
|
|
||
| # Your Packet user account | ||
| if [ "$PACKET_AUTH_TOKEN" == "" ]; then |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: paulfantom, spangenberg The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
| ssh_path="/tmp/packet_id_rsa.pub" | ||
| fi | ||
| terraform init -input=false | ||
| terraform plan -input=false -out=tfplan.out && terraform apply -input=false -auto-approve tfplan.out |
There was a problem hiding this comment.
As we have -e this could be two separate commands.
There was a problem hiding this comment.
Right, I will fix that in a follow-up PR
hack/packet-provision.sh
Outdated
| ;; | ||
| "destroy") | ||
| terraform destroy -input=false -auto-approve | ||
| rm /tmp/packet_id_rsa* || : |
There was a problem hiding this comment.
Why not use rm -f, instead of ||?
| #/bin/bash | ||
|
|
||
| yum install -y -d1 libvirt libvirt-daemon-kvm | ||
| usermod -aG libvirt root |
There was a problem hiding this comment.
Not sure I've looked to see how this script is used (or when) but do you not need newgrp libvirt here having modified the groups?
There was a problem hiding this comment.
It is used to install libvirt on packet host the easiest way.
|
|
||
| iptables -I INPUT -p tcp --dport 16509 -j ACCEPT -m comment --comment "Allow insecure libvirt clients" | ||
|
|
||
| systemctl start libvirtd |
There was a problem hiding this comment.
Do we also need systemctl enable libvirtd? Is there any expectation of this starting on reboot?
There was a problem hiding this comment.
No, those machines aren't expected to be rebooted.
Incorporate suggestions from #22
Add a script to provision packet machine and configure it so we can connect to it with libvirt client via SSH or TCP. It also automatically creates temporary ssh key file if needed (default behavior).
/wip